Particular tags are important to key identification and lineage. These tags relate to what's called the genealogical summary paragraph and child list in a Register or Quarterly styled genealogical biography.
These key tags are birth (and birth related), death (and death related), link/relationship to parents, marriage(s) (and marriage related), Spouse's/Spouses' name, birth, death; spouses link/relationship to parents.
In the child list, these same factors are key, with the added concept of birth order.
Once the table is complete each DEV only needs to create a sync list of it for thier own app.
Also this give the visitors and watchers see what BG is trying to acknowledge as a datafield and where we are with it.
1 _SCHEMA
2 INDI
3 _FA1
4 LABL Fact 1
3 _FA2
4 LABL Fact 2
3 _FA3
4 LABL Fact 3
OR.......
4 LABL Fact 13
3 _MREL
4 LABL Relationship to Mother
3 _FREL
4 LABL Relationship to Father
2 FAM
3 _FA1
4 LABL Marriage fact
3 _FA2
4 LABL Fact 2
3 _MSTAT
0 @F112@ FAM
1 HUSB @I352@
1 WIFE @I353@
1 CHIL @I134@
2 _FREL Natural
2 _MREL Natural
There are many tags we can get an idea what they are use for but some even I wonder what the prupose was or how to sync to them to properly include them
If you can't find that someone else has already researched these tags and listed what they all mean, I'm afraid it's up to you or anyone else interested to make the contacts necessary to figure them all out. But I'll bet you can get a good indication of what they all mean with a little googling.
Tom Wetmore
Yes, I can, it is just sad that when a app strives to be the software supremeO they talk about the structuresand models but leave the users and devs having to resort to riddels and trying to peice meal information together.
This is the whole point guess there never was any push to be open about trading data. If devs could not peice the riddles 100% they would cutthe data out and move on. or made their own tags as exports and had the opinion "deal with it yourself".
That i am trying to avoid.
Mike, Tom:
First, GEDCOM 5.5 (I would use 5.5.1) defines all the tags that are valid. Mike, if you want a list, the GEDCOM spec itself is the best place to go.
The Schema system was deprecated prior to 5.5. Lots of old GEDCOMs, especially FTM, use it, but they use it very trivially. It was an attempt to extend the language, but was deemed too complex for most programmers to want to implement.
But I don't know why you are going through so much trouble. Tags are not the most important part of BetterGEDCOM. In fact, I'd like to minimize them, and allow custom tags. Why if we could get away with essentials like birth, death and marriage and use the generic "EVENT" with a "TYPE" descriptor for everything else, that might work fine.
Custom tags are a GOOD thing about GEDCOM in my eyes - not a bad thing. They allow extension in a trivial way.
I don't really see any purpose in enumerating all the tags used by all the programs.
I think I am qualified to say that, because my program attempts to read in all the flavors of GEDCOM and output a meaningful report. I refer to that as Extended-GEDCOM, because many programs do not follow GEDCOM to the T.
When I encounter a GEDCOM with a new tag, if it doesn't pass through and display correctly like a generic event, then I add some custom code to display it adequately. But that is the exception rather than the rule. In a way, I do almost the same as Tom's Lifelines program does: I read in the GEDCOM directly, make trivial internal changes to convert it to my Extended-GEDCOM data structure, and store it that way.
If I was going to read a BetterGEDCOM file, I would read it in directly, and again convert it to my Extended-GEDCOM data structure.
The key thing here is and my opinion always has been that GEDCOM isn't all that bad. We will always need records for INDI and SOUR and REPO and NOTE and OBJE, we are in debate on whether or not to use FAM, and we probably want to add EVENT and PLAC and CITE and GROUP and some structures for storing the evidence and conclusion models.
Those Records (as they're called in GEDCOM) or Entities (as we seem to be calling them for BetterGEDCOM) are what are important to flesh out. That's what I feel BG needs to work out first, along with the structure/definition of those entities.
Tags that are needed will only become clear once that work is done first.
I especially agree with the point that GEDCOM is not all that bad, and that the addition of EVENT, PLACE, GROUP records, with ability to handle evidence and conclusions is EXACTLY the way for Better GEDCOM to go. If anyone would care to read the DeadEnds model document one more time one will find that the DeadEnds model is essentially exactly this extended GEDCOM idea. Let me draw some parallels ...
DeadEnds Person Record == GEDCOM INDI record.
DeadEnds Vital Structures == GEDCOM event structures (e.g., BIRT, DEAT) within INDI records.
DeadEnds Relation Structures == GEDCOM associations (ASSO tag) allowing the establishment of relationships between persons without requiring events structures or event records.
DeadEnds Attributes == All the tags and value sets needed in all contexts to provide the PACTs in all record types.
DeadEnds Person References in Person Records == part of GEDCOM extension to handle evidence & conclusions.
DeadEnds Event Record == GEDCOM EVENT record extension required to properly handle events.
DeadEnds Role References in Person and Event Records == inter record linkages needed to connect INDI records with the new EVENT records.
DeadEnds Event References in Event Records == part of GEDCOM extension to handle evidence & conclusions.
DeadEnds Group Record == GEDCOM GROUP record extension, including the GEDCOM FAM record.
DeadEnds Place Records == GEDCOM PLACE record extension to avoid duplication in place information and other good things.
DeadEnds Note Records == GEDCOM NOTE records.
DeadEnds Source Records == GEDCOM SOUR records.
DeadEnds URL Records == GEDCOM OBJE records.
DeadEnds General Entity Records == no proposed GEDCOM extension for.
I am not ready to give up the Family record yet though I understand how it can logically be thought of as a sub type of the Group record.
I am also not convinced of the need for a Citation record. For me a Citation is nothing more than a string that can be generated automatically by looking at the chain of sources for the record in question, created by filling in citation templates that can be extracted from various style manuals.
The fact that I used XML as the language for expressing the DeadEnds model is IMMATERIAL to this point. DeadEnds records can be expressed in GEDCOM syntax using exactly GEDCOM tags wherever possible. The decision on the use of GEDCOM versus XML as the format for the transport file format is wholly independent of any aspect of the structure of the data model behind Better GEDCOM. It is a decision orthogonal to all others having to do with the model itself.
In my humble opinion my DeadEnds model has nearly completely worked out all issues for extending GEDCOM as needed to properly cover events, places, evidence & conclusions, and the necessary ways to express relationships between people. I suggest that it be used as one of the starting points for considering ideas for extending GEDCOM.
Tom Wetmore
Are you able to provide an array of reasonably complex examples to explain why you believe citations are "nothing more than a string that can be generated automatically by looking at the chain of sources for the record in question, created by filling in citation templates that can be extracted from various style manuals."
The _Evidence Explained..._ series by Elizabeth Shown Mills has got to be high on the list of authorities work we advance as part of BetterGEDCOM.
There are template-like examples in the _Evidence Explained_ series, however, those are examples of *principles* and *practices.* The templates are not intended to cover all combinations and permutations of those underlying practices.
Tom Jones work with inferential genealogy is surely another authority "high on the list."
What oldGEDCOM called the citation houses much of the heart and soul of my reasoning. I don't see how we can, say we are advancing the evidence-conclusion process if we diminish the record of our reasoning.
Thank you. --GJ
I will put together a simple example. Here are some off the cuff definitions that provides the background.
Source == Something in the real world that contains evidence of genealogical significance. The classic example is a book.
Source Record == A record in a database that describes a Source. For a book this would be a record with the book's author, title, and publication information.
Source Reference == A reference inside a genealogical record in a database (e.g., a Person or Event Record) that points to/refers to the Source Record that describes the Source that holds the evidence that justifies that particular genealogical record. The Source Reference may further discriminate the Source, the best example of this being is providing the page number in a book Source where the specific evidence was found. That is, it is better not to put page numbers inside Source Records, but to put them in the particular references that refer to the Source Record.
Citation == A string to be used in a footnote or as a bibliography entry that describes a Source in an agreed upon conventional format with different parts in specified locations in the string, with specified rules about fonts and quotation marks. This string is automatically generateable by finding the necessary information in the Source Reference (e.g., page number) and in the Source Record referred to (e.g., title, name, publication information.) That is, everything you need to create a citation string is already in the database in Source Records and Source References. There is no need for an additional record type.
Tom Wetmore
just with that I can understand your structure much better. I can look back and not get confused. Your "Source" is like my "source" and your "source record" is like my "eid". Noe when others talk and post I see I will not mistake records in source or as in yours "source record" is a sub of "source" not a source it self.
Just simple outlines like this if all did this, we could all get specific about pin point topics.
I will start a new thread because Louis, Tom, others and myself kind of have grips about FAM. I am wondering the root - like, dislike. "this will be a new topic"
Stuff like this when/if also others display transparency create clarity to the conversations so when a person talk about "x" others will not assume "z" is include in the discussion. I was at fault a few times of that.
Thank you.
Is there a different page on the wiki where we could start a discussion thread and continue this dialog?
The reason I suggested we look some reasonably complex examples is to move the discussion beyond identifying isolated information that might come from a published book or modern day certificates/vital records.
Would also like to bring up Mark Tucker's work about ideas for online sources. He even had a blog entry called Marc XML. http://www.thinkgenealogy.com/2009/06/20/better-online-citations-marc-xml/
We know that import export error log can track data that is dropped flagged and such.
Picture an export, AFTER the fact of a BG standard. an APP comes up with a custom TAG called "_WXYZ" what it will do is export it and any other "_TUVW" to a "_CATCHALL".
That catchall place will hold data "gedcomISH" like so
0 INDI
1 NAME
2
1
2
3
1 _CTAL
2 CONT Hair Color Brown
2 CONC shoe size 9
2 CONC fav food pizza
or in xml like
<set>
<INDI>I5436</INDI>
<NAME>John P./Smith</NAME>
<CTAL>Hair Color Brownshoe size 9fav food pizza</CTAL>
</set>
this way if there is unsync data the DATA can still be exported and handled. Even imported as well.
The user can open a dashboard and view the data like a note. If that new app handles such data fileds the user can create PROPER data entry and go back to that note catch all and delete such error transffered data.
This approach can be a safty net for data that comes after the fact or during such an import NOT to drop data that may be very vital information.
<CTAL>Hair Color Brown : shoe size 9 : fav food pizza</CTAL>
my "/" for : made the text font change?
If not just delete it or edit and rename it to a better understanding if there is one.
Some posting on this topic might have started here http://bettergedcom.wikispaces.com/message/view/20+Dec+2010+Organizers+Meeting+Notes/31994709
If so if you export your file as a pure gedcom like file. would other programs chop off your long than permitted strings?
If so if you export your file as a pure gedcom like file. would other programs chop off your long than permitted strings?"
My software doesn't limit the length of GEDCOM lines so does not truncate long lines on import. However most users probably keep the values relatively short and use CONT lines to continue long values. I can't say what other programs would do on importing lines with very long values.
Tom Wetmore
I use the 5.5 specifications whenever I have a question about interpreting tags, and can generally figure out what I need to know from there. I have also seen a number of web sites that list the valid tags and give them short descriptions.
Tom Wetmore